The present invention relates to the tracing of the execution of a program, and more specifically to displaying the trace of the execution of a program that is described in a logic programming language.
Execution of a program is usually traced to assist the debugging operation. It is therefore desired to be able to easily grasp at any time which part of the program is being executed based upon the trace data that is displayed.
A conventional system for tracing the execution of a program in the logic programming language processing system has been discussed in a journal "PROLOG PROGRAMMING", published by Micro Software Co., 1983, pp. 197-222.
According to the conventional logic processing system, there are independently provided a function (tracing function) for successively displaying which clause was selected as a result of calling a procedure, in order to display the execution status, a function for displaying a sequence of calling clauses to indicate by which clause it was called, and a function for displaying all clauses in the procedure including the selected clauses.
According to the conventional function for tracing the logic programming language program, which one of control points of the term is passed is displayed, i.e., which one of call (CALL), recall (REDO), success termination (EXIT) or fail termination (FAIL) is passed, is displayed successively in the form of a list by a character train together with the procedures and terms that are to be executed (W. F. Clockskin, C. S. Mellish, "PROGRAMMING IN PROLOG" published from Springer-Verlag Berlin, Heidelberg, New York).
FIG. 11 illustrates an example of the execution trace display of the type that belongs to the conventional art in relation to a prolog program shown in FIG. 4A. In this example, in addition to the above-mentioned four points, the control points further include special cases, i.e., unification call (UCALL), unification recall (UREDO), unification success termination (UEXIT) and unification fail termination (UFAIL). Instead of the previously mentioned control points, these additional control points are used for the head term of a sentence. In FIG. 11, numerals at the extreme left end denote levels of the procedures, columns to the right denote control points among the above-mentioned eight kinds of control points that are passed, and the columns on the extreme right side denote terms and the like that are to be executed.
FIG. 11 shows an execution trace display 111 of the case when an interrogation clause "P(x)" is input to a user program of FIG. 4A, a display command 112 of a sequence of calling clauses at that moment, a display 113 of a sequence of calling clauses displayed according to the display command 112, a display command 114 of all clauses in the procedure that is to be called, and a display 115 displayed according to the display command 114. Here, for example, the fourth line indicates that a term r (2, X) requesting the trial of procedure r has passed the CALL point, the fifth line indicates that the head term r (1, X) of a sentence r(1, X):-s(X) of the procedure r has passed the UCALL point, the sixth line indicates that the term has passed the point UFAIL, the seventh line indicates that the head term r (2, X) of a next sentence r(2, X):-t(X), s(X) of the procedure r has passed the UCALL point, the eighth line indicates that the term has passed the UEXIT point, and the ninth line indicates that the second term t(X) of the sentence has passed the CALL point and the procedure t is tried in the next time.
It has already been proposed to surround the terms of a program of the logic language with a box-like figure and to display the change of call and the past execution status for the terms using four sides of the box-like figure (Japanese Patent Application Nos. 195280/1985 and 195848/1985, U.S. patent application Ser. No. 895,954, Registration No. 4,794,529, and European Patent Application No. 86111186.2 that correspond to the above latter Japanese application). These proposals, however, have not yet reached the level for displaying the execution trace.
The conventional execution trace display, call sequence display, and display of all clauses in the procedure to be called, shown in FIG. 11, are not sufficient with regard to the amount of data. However, it is not easy to grasp from the display which portion of the program is being executed. In the program of logic language, furthermore, the back tracking develops so frequently that a simple indication of the present point of execution does not suffice for the requirement. It is necessary to grasp the process that led up to this point which, however, is more difficult to attain.
When the execution status of a program described by the logic language is to be understood from the standpoint of executing the program debugging, it is necessary to grasp not only the result of clause selection of which clause was selected for the calling of procedure but also to grasp (1) the object of clause selection, i.e., which clause was verified by calling the procedure, and (2) the reason for selecting the clause, i.e., why a particular clause was selected but other clauses were not selected.
Display of a sequence of calling clauses is effective for grasping the object of clause selection. Further, the reason of clause selection can be effectively grasped by displaying all clauses in the procedure inclusive of the selected clause while clearly indicating the above selected clause. According to the prior art, however, attention has not been given to the fact that the above two are simultaneously required. The progammer must designate the display of a sequence of calling clauses and the display of the whole procedures, and must determine the correspondence among the data that are independently displayed based upon these designations, causing the efficiency of the program debugging operation to decrease.
Further, the programmer usually describes a program in an easily-to-understand form by effecting indention, starting with a new line and inserting a note within a range permitted by the language specifications, and comprehends the program in this particularly described form. When the debugging is carried out while making reference to the trace display of the form shown in FIG. 11, therefore, many program writers are obliged to separately prepare a program source list output of a type described by themselves, and infer and determine the present point of execution on the program source list and procedure that leads to that point based upon the trace data shown in FIG. 11. The labor required for the inference and decision prevents the debugging operation from being improved.